ehwa_unnt_kabahlfandomcom_de-20200214-history
Linux
), enthält verschiedene | Website = www.kernel.org }} Linux ( ˈliːnʊks}}) ist ein Betriebssystem-Kernel, der im Jahr 1991 von Linus Torvalds ursprünglich für die x86-Architektur entwickelt und ab Version 0.12 unter der freien GNU General Public License (GPL) veröffentlicht wird. Er ist heute Teil einer Vielzahl von Betriebssystemen. Der Name Linux setzt sich zusammen aus dem Namen Linus und einem X für das als Vorbild dienende Unix. Er bezeichnet im weiteren Sinne mittlerweile nicht mehr nur den Kernel selbst, sondern übertragen davon ganze Linux-basierte Systeme und Distributionen. Dies führte zum GNU/Linux-Namensstreit. Grundlegende Technologie mini|Grob-Struktur des Linux-Kernels Aufgaben des Kernels Der Kernel eines Betriebssystems bildet die hardwareabstrahierende Schicht, das heißt, er stellt der auf dieser Basis aufsetzenden Software eine einheitliche Schnittstelle (API) zur Verfügung, die unabhängig von der Rechnerarchitektur ist. Die Software kann so immer auf die Schnittstelle zugreifen und braucht die Hardware selbst, die sie nutzt, nicht genauer zu kennen. Linux ist dabei ein modularer monolithischer Kernel und zuständig für Speicherverwaltung, Prozessverwaltung, Multitasking, Lastverteilung, Sicherheitserzwingung und Eingabe/Ausgabe-Operationen auf verschiedenen Geräten. Programmiersprache Linux ist fast ausschließlich in der Programmiersprache C geschrieben, wobei einige GNU-C-Erweiterungen benutzt werden. Eine Ausnahme bilden die architekturabhängigen Teile des Codes (im Verzeichnis arch innerhalb der Linux-Sourcen), wie zum Beispiel der Beginn des Systemstarts (Bootvorgang), der in Assemblersprache geschrieben ist. Funktionsweise Bei einem strikt monolithischen Kernel wird der gesamte Quellcode inklusive aller Treiber in das Kernel-Image (den ausführbaren Kernel) kompiliert. Im Gegensatz dazu kann Linux Module benutzen, die während des Betriebs geladen und wieder entfernt werden können. Damit wird die Flexibilität erreicht, um unterschiedlichste Hardware ansprechen zu können, ohne sämtliche (auch nicht benötigte) Treiber und andere Systemteile im Arbeitsspeicher halten zu müssen. Sind Teile der Hardwarespezifikationen nicht genügend offengelegt, so stützt sich Linux notfalls über spezielle VM86-Modi auch auf das BIOS des Systems, u. a. auf die Erweiterungen gemäß den Standards APM, ACPI und VESA. Um unter diesen Voraussetzungen x86-kompatible Hardware z. B. auf der DEC-Alpha-Plattform zu betreiben, werden teilweise sogar Emulatoren zur Ausführung entsprechenden ROM-Codes verwendet. Linux selbst übernimmt das System beim Bootprozess typischerweise in dem Moment, in dem der BIOS-Bootloader erfolgreich war und alle Systeminitialisierungen des BIOS abgeschlossen sind. Der Kernel ist ein Betriebssystemkern und darf nicht als das eigentliche Betriebssystem verstanden werden. Dieses setzt sich aus dem Kernel und weiteren grundlegenden Bibliotheken und Programmen (die den Computer erst bedienbar machen) zusammen. Siehe auch: Gerätedatei, Network Block Device, Netfilter, Netzwerk-Scheduler, Prozess-Scheduler, Linux (Betriebssystem) Schnittstellen mini|[[Linux Standard Base]] Man kann zwischen vier Schnittstellen unterscheiden, die das Zusammenwirken von entweder kernelinternen Komponenten untereinander oder von Kernel und externer Software ermöglichen. Die Stabilität der externen Programmierschnittstelle wird garantiert, das heißt, dass Quellcode grundsätzlich ohne jegliche Veränderungen portierbar ist. Die Stabilität der internen Programmierschnittstellen wird nicht garantiert, diese können zehn Jahre oder wenige Monate stabil bleiben. Da der Linux-Kernel von einigen tausend Entwicklern vorangetrieben wird, ist der eventuell entstehende Aufwand zu verschmerzen. Die Binärschnittstelle des Kernels ist unerheblich, auf das komplette Betriebssystem kommt es an. Die Linux Standard Base (LSB) soll es ermöglichen, kommerzielle Programme unverändert zwischen Linux Betriebssystemen zu portieren. Die interne Binärschnittstelle ist nicht stabil, und es gibt keinerlei Bestrebungen dies zu ändern; dies hat zur Folge, dass ein internes Modul, welches z. B. für Linux 3.0 kompiliert worden ist, höchstwahrscheinlich nicht mit Linux-Kernel 3.1 zusammenarbeiten wird. Dies ist eine ganz bewusste Entscheidung.index : kernel/git/torvalds/linux.git Architektur Linux ist ein monolithischer Kernel. Die Treiber im Kernel und die Kernel-Module laufen im privilegierten Modus (x86: Ring 0), haben also unbeschränkten Zugriff auf die Hardware. Einige wenige Module des Kernels laufen im eingeschränkten Benutzermodus (x86: Ring 3). Die Level 1 und 2 der x86-Architektur werden von Linux nicht genutzt, da sie auf vielen anderen Architekturen nicht existieren und der Kernel auf allen unterstützten Architekturen im Wesentlichen gleich funktionieren soll. Nahezu jeder Treiber kann auch als Modul zur Verfügung stehen und vom System dann dynamisch nachgeladen werden. Ausgenommen davon sind Treiber, die für das Starten des Systems verantwortlich sind, bevor auf das Dateisystem zugegriffen werden kann. Man kann allerdings den Kernel so konfigurieren, dass ein CramFS- oder Initramfs-Dateisystem vor dem tatsächlichen Root-Dateisystem geladen wird, welches die weiteren für den Startprozess notwendigen Module enthält. Dadurch kann die Kernelgröße verringert und die Flexibilität drastisch erhöht werden. Im System laufende Programme bekommen wiederum vom Kernel Prozessorzeit zugewiesen. Jeder dieser Prozesse erhält einen eigenen, geschützten Speicherbereich und kann nur über Systemaufrufe auf die Gerätetreiber und das Betriebssystem zugreifen. Die Prozesse laufen dabei im Benutzermodus ( ), während der Kernel im Kernel-Modus ( ) arbeitet. Die Privilegien im Benutzermodus sind sehr eingeschränkt. Abstraktion und Speicherschutz sind nahezu vollkommen, ein direkter Zugriff wird nur sehr selten und unter genau kontrollierten Bedingungen gestattet. Dies hat den Vorteil, dass kein Programm z. B. durch einen Fehler das System zum Absturz bringen kann. Linux stellt wie sein Vorbild Unix eine vollständige Abstraktion und Virtualisierung für nahezu alle Betriebsmittel bereit (z. B. virtueller Speicher, Illusion eines eigenen Prozessors usw.). Die Tatsache, dass Linux nicht auf einem Microkernel basiert, war Thema eines berühmten Flame Wars zwischen Linus Torvalds und Andrew S. Tanenbaum. Anfang der 1990er Jahre, als Linux entwickelt wurde, galten monolithische Kernels als obsolet (Linux war zu diesem Zeitpunkt noch rein monolithisch). Die Diskussion und Zusammenfassungen sind im Artikel Geschichte von Linux näher beschrieben. Durch Erweiterungen wie FUSE und durch die zunehmende Verwendung von Kernel-Prozessen fließen mittlerweile auch zahlreiche Microkernel-Konzepte in Linux ein. Portierbarkeit Obwohl Linus Torvalds eigentlich nicht beabsichtigt hatte, einen portierbaren Kernel zu schreiben, hat sich Linux dank des GNU Compilers GCC weitreichend in diese Richtung entwickelt. Es ist inzwischen eines der am häufigsten portierten Systeme (nur noch NetBSD läuft auf etwa gleich vielen Architekturen). Das Repertoire reicht dabei von eher selten anzutreffenden Betriebsumgebungen wie dem iPAQ-Handheld-Computer, Digitalkameras oder Großrechnern wie IBMs System z bis hin zu normalen PCs. Obwohl die Portierung auf die S/390 ursprünglich ein vom IBM-Management nicht genehmigtes Unterfangen war (siehe auch: Skunk works), plant IBM auch die nächste IBM-Supercomputergeneration Blue Gene mit einem eigenen Linux-Port auszustatten. Ursprünglich hatte Torvalds eine ganz andere Art von Portierbarkeit für sein System angestrebt, nämlich die Möglichkeit, freie GPL- und andere quelloffene Software leicht unter Linux kompilieren zu können. Dieses Ziel wurde bereits sehr früh erreicht und macht sicherlich einen guten Teil des Erfolges von Linux aus, da es jedem eine einfache Möglichkeit bietet, auf einem freien System freie Software laufen zu lassen. Die ersten Architekturen, auf denen Linux lief, waren die von Linus Torvalds verwendeten Computer: * IA-32 ab i386 – Linus hatte ab 1991 einen PC mit Intel-386DX-33-MHz-Prozessor, 4 MB RAM und 40 MB Festplatte. * Alpha – Linus arbeitete von 1994 bis 1995 an der Portierung auf die 64-Bit-Alpha-Architektur (auf einem DEC-Alpha-Rechner, den er als Leihgabe erhalten hatte). Damit war Linux sehr früh 64-Bit-fähig (Linux 1.2 erschien 1995) und durch die Portierung auf Alpha war der Weg für weitere Portierungen frei. Zeitgleich arbeitete der Student Dave Miller ab 1993 an der Portierung auf SPARC von Sun Microsystems, einer damals weit verbreiteten Architektur. Doch lief Linux 2.0 von Mitte 1996 offiziell auf IA-32 und Alpha, konnte aber bereits SMP. Mit Linux 2.2 vom Januar 1999 kamen folgende Ports hinzu: * SPARC/UltraSPARC von Sun * 68000 (m68k) von Motorola * PowerPC (ppc) von Apple, IBM und Motorola (AIM-Allianz) Mit Linux 2.4 vom Januar 2001 schließlich kamen folgende Architekturen hinzu: * Itanium (IA-64) von Intel und HP * S/390 von IBM * SuperH von Hitachi * MIPS Trotz der unterstützten Befehlssatzarchitekturen ( , kurz ISA) ist für die Lauffähigkeit mehr nötig, sodass Linux gegenwärtig auf u. a. folgenden Plattformen und Architekturen läuft: * Acorn Archimedes, A5000 und Risc-PC-Serie (ARM, StrongARM, Intel XScale usw.) * x86-64 bzw. x64 (implementiert als AMD64 oder Intel 64): alle x86-Prozessoren mit 64-Bit-Erweiterung (trotzdem weiterhin IA-32-Architektur), wie AMDs Athlon 64, Opteron, Turion, Phenom, Phenom II, Bulldozer sowie Intels Core 2, Core i, Xeon * Atmel AVR32 * Axis Communications' CRIS * Blackfin * Compaq Alpha-Prozessor * Hitachi H8/300 * Hewlett-Packard PA-RISC * IA-64: PCs mit 64-Bit-Intel-Itanium-Prozessor * IBM S/390 und System z * Intel 80386 (bis Kernel 3.7, Anfang 2013): |werk= |hrsg= |datum=2013-02-20 |zugriff=2013-04-14 |sprache=en}} IBM-PCs und kompatible mit 80386- und dazu kompatiblen x86-Prozessoren derselben Generation * Intel 80486 und neuer: IBM-PCs und kompatible mit 32-Bit-Prozessoren der IA-32-Architektur, u. a. Intel 80486 und Pentium, AMD Athlon und Duron, Cyrix-Prozessoren und viele weitere. * Unterstützung für Intel-16-Bit-CPUs (8086, 8088, 80186, 80188 und 80286) wird im Rahmen des ELKS-Projektes entwickelt. ELKS steht für Embeddable Linux Kernel Subset und ist eine Kernel-Untermenge. * MIPS: Maschinen von Silicon Graphics … * Motorola 68020 und neuer: spätere Amigas, einige Atari und viele Apple Computer ab 1987 (Macintosh II) bis 1995 (siehe Linux68k) * NEC v850e * PowerPC: die meisten Apple Computer zwischen 1994 und 2006 (alle PCI-basierten Power Macintosh, der Nintendo GameCube; begrenzte Unterstützung für NuBus Power Macs bis Kernel 2.4.x, die weitere Entwicklung wurde in das Projekt PPC/Linux for NuBus Power Macs ausgelagert ), Clones der Power Macs von Power Computing, UMAX und Motorola, mit einer „Power-UP“-Karte verbesserte Amigas (z. B. Blizzard oder CyberStorm) bzw. dessen Nachfolger AmigaOne, sowohl IBM Power als auch PowerPC-basierte IBM RS/6000-Systeme, verschiedene eingebettete PowerPC-Plattformen * Sun SPARC und UltraSparc: Sun-Workstations * Hitachi SuperH: Sega Dreamcast * OpenRISC Binärschnittstellen der ARM-Architektur Linux unterstützt zwei verschiedene ''Binär''schnittstellen für ''ARM''-Rechenwerke. Die Ältere wird mit der englischen Abkürzung OABI bezeichnet, was ausgeschrieben für old application binary interface steht, und unterstützt die Rechenwerke einschließlich ARMv4, während die Neuere, die mit EABI (kurz für embedded application binary interface) bezeichnet wird, welche Rechenwerke einschließlich ARMv4 unterstützt. Der bedeutendste Unterschied der Schnittstellen in Bezug auf Systemleistung ist die sehr viel bessere Unterstützung von softwareemulierten Gleitkomma-Berechnungen durch EABI.Why ARM’s EABI matters (englisch) – bei LinuxDevices von Andres Calderon und Nelson Castillo, am 14.3.2007 User Mode Linux Ein besonderer Port ist das User Mode Linux. Prinzipiell handelt es sich dabei um einen Port von Linux auf sein eigenes Systemcall-Interface. Dies ermöglicht es, einen Linux-Kernel als normalen Prozess auf einem laufenden Linux-System zu starten. Der User-Mode-Kernel greift dann nicht selbst auf die Hardware zu, sondern reicht entsprechende Anforderungen an den echten Kernel durch. Durch diese Konstellation werden „Sandkästen“ ähnlich den virtuellen Maschinen von Java oder den jails von FreeBSD möglich, in denen ein normaler Benutzer Root-Rechte haben kann, ohne dem tatsächlichen System schaden zu können. µClinux µClinux ist eine Linux-Variante für Computer ohne Memory Management Unit (MMU) und kommt vorwiegend auf Mikrocontrollern und eingebetteten Systemen zum Einsatz. Seit Linux-Version 2.6 ist µClinux Teil des Linux-Projektes. Entwicklungsprozess mini|hochkant|Linus Torvalds (2014) Die Entwicklung von Linux liegt durch die GNU General Public License und durch ein sehr offenes Entwicklungsmodell nicht in der Hand von Einzelpersonen, Konzernen oder Ländern, sondern in der Hand einer weltweiten Gemeinschaft vieler Programmierer, die sich hauptsächlich über das Internet austauschen. Bei der Entwicklung kommunizieren die Entwickler fast ausschließlich über E-Mail, da Linus Torvalds behauptet, dass so die Meinungen nicht direkt aufeinander prallen. In vielen Mailinglisten, aber auch in Foren und im Usenet besteht für jedermann die Möglichkeit, die Diskussionen über den Kernel zu verfolgen, sich daran zu beteiligen und auch aktive Beiträge zur Entwicklung zu leisten. Durch diese unkomplizierte Vorgehensweise ist eine schnelle und stetige Entwicklung gewährleistet, die auch die Möglichkeit mit sich bringt, dass jeder dem Kernel Fähigkeiten zukommen lassen kann, die er benötigt. Eingegrenzt wird dies nur durch die Kontrolle von Linus Torvalds und einigen besonders verdienten Programmierern, die das letzte Wort über die Aufnahme von Verbesserungen und Patches in die offizielle Version haben. Manche Linux-Distributoren bauen auch eigene Funktionen in den Kernel ein, die im offiziellen Kernel (noch) nicht vorhanden sind. Änderungen der Herkunftskontrolle Der Entwicklungsprozess des Kernels ist wie der Kernel selbst ebenfalls immer weiterentwickelt worden. So führte der Rechtsprozess der SCO Group um angeblich illegal übertragenen Code in Linux zur Einführung eines „Linux Developer's Certificate of Origin“, das von Linus Torvalds und Andrew Morton bekanntgegeben wurde.Pressemitteilung OSDL: Developer's Certificate of Origin, 2004 Diese Änderung griff das Problem auf, dass nach dem bis dahin gültigen Modell des Linux-Entwicklungsprozesses die Herkunft einer Erweiterung oder Verbesserung des Kernels nicht nachvollzogen werden konnte. Das Versionskontrollsystem Git Die Versionskontrolle des Kernels unterliegt dem Programm Git. Dies wurde speziell für den Kernel entwickelt und auf dessen Bedürfnisse hin optimiert. Es wurde im April 2005 eingeführt, nachdem sich abgezeichnet hatte, dass das alte Versionskontrollsystem BitKeeper nicht mehr lange für die Kernelentwicklung würde genutzt werden können. Kernel-Versionen Auf der Website kernel.org werden alle alten und neuen Kernel-Versionen archiviert. Die dort befindlichen Referenzkernel werden auch als Vanilla-Kernel bezeichnet (von umgangssprachlich engl. vanilla für Standard bzw. ohne Extras im Vergleich zu Distributionskernels). Auf diesem bauen die Distributionskernel auf, die von den einzelnen Linux-Distributionen um weitere Funktionen ergänzt werden. Die Kernel-Version des geladenen Betriebssystems kann mit dem Befehl uname -r abgefragt werden. Versionsnummern-Schema Die frühen Kernelversionen (0.01 bis 0.99) hatten noch kein klares Nummerierungsschema. Version 1.0 sollte die erste „stabile“ Linux-Version werden. Beginnend mit Version 1.0 folgen die Versionsnummern von Linux einem bestimmten Schema: Die erste Ziffer wird nur bei grundlegenden Änderungen in der Systemarchitektur angehoben. Während der Entwicklung des 2.5er Kernels kam wegen der relativ grundlegenden Änderungen, verglichen mit dem 2.4er Kernel, die Diskussion unter den Kernel-Programmierern auf, den nächsten Produktionskernel als 3.0 zu deklarieren. Torvalds war aber aus verschiedenen Gründen dagegen, sodass der resultierende Kernel als 2.6 bezeichnet wurde. Die zweite Ziffer gibt das jeweilige „Majorrelease“ an. Bisher wurden stabile Versionen (Produktivkernel) von den Entwicklern stets durch gerade Ziffern wie 2.2, 2.4 und 2.6 gekennzeichnet, während die Testversionen (Entwicklerkernel) immer ungerade Ziffern trugen, wie zum Beispiel 2.3 und 2.5; diese Trennung ist aber seit Juli 2004 ausgesetzt, es gab keinen Entwicklerkernel mit der Nummer 2.7, stattdessen wurden die Änderungen laufend in die 2.6er-Serie eingearbeitet. Zusätzlich bezeichnet eine dritte Zahl das „Minorrelease“, das die eigentliche Version kennzeichnet. Werden neue Funktionen hinzugefügt, steigt die dritte Zahl an. Der Kernel wird damit zum Beispiel mit einer Versionsnummer wie 2.6.7 bestimmt. Um die Korrektur eines schwerwiegenden NFS-Fehlers schneller verbreiten zu können, wurde mit der Version 2.6.8.1 erstmals eine vierte Ziffer eingeführt. Seit März 2005 (Kernel 2.6.11) wird diese Nummerierung offiziell verwendet. So ist es möglich, die Stabilität des Kernels trotz teilweise sehr kurzer Veröffentlichungszyklen zu gewährleisten und Korrekturen von kritischen Fehlern innerhalb weniger Stunden in den offiziellen Kernel zu übernehmen – wobei sich die vierte Ziffer erhöht (z. B. von 2.6.11.1''' auf 2.6.11.'''2). Die Minorreleasenummer, also die dritte Ziffer, wird hingegen nur bei Einführung neuer Funktionen hochgezählt. Im Mai 2011 erklärte Linus Torvalds, die nach der Version 2.6.39 kommende Version nicht 2.6.40, sondern 3.0 zu benennen. Als Grund dafür führte er an, dass die Versionsnummern seiner Meinung nach zu hoch wurden. Die Versionsnummer '3' stehe gleichzeitig für das dritte Jahrzehnt, welches für den Linux-Kernel mit seinem 20. Geburtstag anfange. Bei neuen Versionen wird seitdem die zweite Ziffer erhöht und die dritte steht – anstelle der vierten – für Bugfixreleases. Im Februar 2015 erhöhte Torvalds auf Version 4.0 statt Version 3.20 nachdem er auf Google+ Meinungen hierzu eingeholt hatte. Seit März 2019 ist Linux 5.0 freigegeben. Dabei hat der Sprung von der letzten Versionsnummer 4.20 auf 5.0 keine tiefergehende Bedeutung. Die aktuelle Version soll eine modernere Speicherfunktion und mehr Geschwindigkeit liefern. Entwicklerversion Neue Funktionen finden sich im ''-mm'' Kernel des Kernelentwicklers Andrew Morton und werden anschließend in den Hauptzweig von Torvalds übernommen. Somit werden große Unterschiede zwischen Entwicklungs- und Produktionskernel und damit verbundene Portierungsprobleme zwischen den beiden Serien vermieden. Durch dieses Verfahren gibt es auch weniger Differenzen zwischen dem offiziellen Kernel und den Distributionskernel (früher wurden Features des Entwicklungszweiges von den Distributoren häufig in ihre eigenen Kernels rückintegriert). Allerdings litt 2004/2005 die Stabilität des 2.6er Kernels unter den häufig zu schnell übernommenen Änderungen. Ende Juli 2005 wurde deshalb ein neues Entwicklungsmodell beschlossen, das nach dem Erscheinen der Version 2.6.13 erstmals zur Anwendung kam: Neuerungen werden nur noch in den ersten zwei Wochen der Kernelentwicklung angenommen, wobei anschließend eine Qualitätssicherung bis zum endgültigen Erscheinen der neuen Version erfolgt. Pflege der Kernel-Versionen Während Torvalds die neuesten Entwicklungsversionen veröffentlicht, wurde die Pflege der älteren „stabilen“ Versionen an andere Programmierer abgegeben. Gegenwärtig ist David Weinehall für die 2.0er Serie verantwortlich, Marc-Christian Petersen (zuvor Alan Cox) für den Kernel 2.2, Willy Tarreau (zuvor Marcelo Tosatti) für den Kernel 2.4, Greg Kroah-Hartman und Chris Wright für die aktuellen stabilen Kernel 3.x.y(-stable), Linus Torvalds für die aktuellen „normalen“ Kernel 4.x.y, und Andrew Morton für seinen experimentellen -mm-Zweig, basierend auf dem neuesten 4.x. Zusätzlich zu diesen offiziellen und über Kernel.org oder einen seiner Mirrors zu beziehenden Kernel-Quellcodes kann man auch alternative „Kernel-Trees“ aus anderen Quellen benutzen. Distributoren von Linux-basierten Betriebssystemen pflegen meistens ihre eigenen Versionen des Kernels und beschäftigen zu diesem Zwecke fest angestellte Kernel-Hacker, die ihre Änderungen meist auch in die offiziellen Kernels einfließen lassen. Distributions-Kernel sind häufig intensiv gepatcht, um auch Treiber zu enthalten, die noch nicht im offiziellen Kernel enthalten sind, von denen der Distributor aber glaubt, dass seine Kundschaft sie benötigen könnte und die notwendige Stabilität respektive Fehlerfreiheit dennoch gewährleistet ist. Versionen mit Langzeitunterstützung Folgende Versionen werden besonders lange mit Support (Long Term Support) versorgt: Versionsgeschichte Zeittafeln mini|Entwicklung der Anzahl Quelltextzeilen Das folgende Schaubild stellt einzelne Versionen des Linux-Kernels anhand der Erscheinungsdaten auf einer Zeittafel angeordnet dar und soll dem Überblick dienen. Versionsgeschichte bis Version 2.6 Versionsgeschichte ab Version 2.6 Bei Betrachtung der zuletzt erschienenen Versionen (siehe Tabelle) erfolgt die Entwicklung einer neuen Kernel-Version in durchschnittlich 82 Tagen. Der Kernel wird hierbei im Durchschnitt um 768 Dateien und 325.892 Quelltextzeilen (englisch Lines of Code) erweitert. Das mit dem Datenkompressionsprogramm gzip komprimierte ''tar''-Archiv (.tar.gz) wächst im Mittel um rund 2 Megabyte mit jeder veröffentlichten Hauptversion. Anmerkungen Neuerungen im Kernel 2.6 Die Kernel-Reihe 2.6 wurde ab Dezember 2001 auf Basis der damaligen 2.4er-Reihe entwickelt und wies umfangreiche Neuerungen auf. Für die Entwicklung war der neue Quelltext übersichtlicher und leichter zu pflegen, während Anwender durch die Überarbeitung des Prozess-Schedulers sowie des I/O-Bereiches und von geringeren Latenzzeiten profitierten.Dr. Oliver Diedrich: The Next Generation – Linux 2.6: Fit für die Zukunft, in der c't 24/2003 (am ), Seite 194 Dies wurde durch eine Reihe von Maßnahmen erreicht, die im Folgenden aufgezeigt werden: Neue Prozess-Scheduler In einem Multitasking-fähigen Betriebssystem muss es eine Instanz geben, die den Prozessen, die laufen wollen, Rechenzeit zuteilt. Diese Instanz bildet der Prozess-Scheduler. Seit dem Erscheinen von Linux 2.6 wurde mehrfach grundlegend am Scheduler gearbeitet. Für die ersten Kernel 2.6 war von Ingo Molnár ein gegenüber Linux 2.4 ganz neuer Scheduler konzipiert und implementiert worden, der O(1)-Scheduler. Dieser erhielt seinen Namen, weil die relevanten Algorithmen, auf denen der Scheduler basierte, die Zeitkomplexität O(1) haben. Dies bedeutet, dass die vom Scheduler für eigene Aufgaben benötigte Prozessorzeit unabhängig von der Anzahl der verwalteten Prozesse bzw. Threads ist. Insbesondere wurde etwa auf das Durchsuchen aller Prozesse nach dem momentan wichtigsten Prozess verzichtet. Der O(1)-Scheduler arbeitete auch bei sehr vielen Prozessen überaus effizient und benötigte selbst sehr wenig Rechenzeit. Er verwendete prinzipiell zwei verkettete Listen, in denen die Prozesse eingetragen waren, die noch laufen wollten, und diejenigen, die bereits gelaufen sind. Wenn alle Prozesse in der zweiten Liste standen, wurden die Datenfelder getauscht, und das Spiel begann von neuem. Der Scheduler war darüber hinaus so ausgelegt, dass Prozesse, die große Mengen Rechenzeit in Anspruch nehmen wollen, gegenüber interaktiven Prozessen benachteiligt werden, wenn beide zur gleichen Zeit laufen wollen. Interaktive Prozesse benötigen in der Regel nur sehr wenig Rechenzeit, sind dafür aber sehr zeitkritisch (so will der Benutzer beispielsweise nicht lange auf eine Reaktion der grafischen Oberfläche warten). Der O(1)-Scheduler besaß Heuristiken, um festzustellen, ob ein Prozess interaktiv ist oder die CPU eher lange belegt. Der interne „Takt“ des Kernels wurde ab dem Kernel 2.6 von 100 auf 1000 Hertz erhöht, das heißt, die kürzestmögliche Länge einer Zeitscheibe beträgt nun eine Millisekunde. Auch hiervon profitieren besonders die interaktiven Prozesse, da sie früher „wieder an der Reihe sind“. Da dies aber zu einer erhöhten CPU-Last und somit zu einem größeren Stromverbrauch führt, entschied man, den Takt ab dem Kernel 2.6.13 auf 250 Hertz voreinzustellen. Bei der Konfiguration des Kernels sind jedoch auch noch die Werte 100, 300 und 1000 Hertz wählbar. Mit der Kernelversion 2.6.23 wurde im Oktober 2007 der O(1)-Scheduler durch einen Completely Fair Scheduler (kurz CFS) ersetzt, der ebenfalls von Ingo Molnár entwickelt wurde. Der CFS als gegenwärtig einziger im Hauptentwicklungszweig verfügbarer Scheduler ist unter den Kernel-Entwicklern teilweise umstritten, da er seinen Schwerpunkt auf Skalierbarkeit auch bei Servern mit vielen Prozessorkernen legt. Entwickler wie Con Kolivas sind der Meinung, dass unter dieser Schwerpunktsetzung sowie einigen Designentscheidungen im CFS die Leistung auf typischen Desktop-Systemen leide. Präemptiver Kernel Der Kernel ist ab Version 2.6 in den meisten Funktionen präemptiv, d. h. selbst wenn das System gerade im Kernel-Modus Aufgaben ausführt, kann dieser Vorgang durch einen Prozess aus dem User-Modus unterbrochen werden. Der Kernel macht dann weiter, wenn der Usermodus-Prozess seine Zeitscheibe aufgebraucht hat oder selbst eine neue Zeitplanung (englisch ) anfordert, also dem Zeitplaner (englisch ) mitteilt, dass er einen anderen Task ausführen kann. Dies funktioniert, bis auf einige Kernel-Funktionen, die atomar (nicht unterbrechbar) ablaufen müssen, sehr gut und kommt ebenfalls der Interaktivität zugute. Zugriffskontrolllisten Mit dem Kernel 2.6 werden für Linux erstmals Zugriffskontrolllisten (englisch ) nativ eingeführt. Diese sehr feinkörnige Rechteverwaltung ermöglicht es vor allem Systemadministratoren, die Rechte auf einem Dateisystem unabhängig vom Gruppen- und Nutzermodell zu gestalten und dabei faktisch beliebig viele spezielle Rechte pro Datei zu setzen. Die mangelnde Unterstützung von Zugriffskontrolllisten von Linux wurde vorher als massive Schwäche des Systems im Rahmen der Rechteverwaltung und der Möglichkeiten zur sicheren Konfiguration gesehen. Die Unterstützung von Zugriffskontrolllisten funktioniert dabei mit den Dateisystemen ext2, ext3, jfs und XFS nativ. Inotify Mit dem Kernel 2.6.13 hielt erstmals eine Inotify genannte Funktion Einzug in den Kernel. Diese ermöglicht eine andauernde Überwachung von Dateien und Verzeichnissen – wird eines der überwachten Objekte geändert oder ein neues Objekt im Überwachungsraum erschaffen, gibt Inotify eine Meldung aus, die wiederum andere Programme zu definierten Tätigkeiten veranlassen kann. Dies ist insbesondere für Such- und Indexierungsfunktionen der Datenbestände von entscheidender Bedeutung, und ermöglicht erst den sinnvollen Einsatz von Desktop-Suchmaschinen wie Strigi oder Meta Tracker. Ohne eine solche Benachrichtigungsfunktion des Kernels müsste ein Prozess die zu überwachende Datei oder das zu überwachende Verzeichnis in bestimmten Zeitintervallen auf Änderungen überprüfen, was im Gegensatz zu Inotify zusätzliche Performance-Einbußen mit sich bringen würde. Weitere wichtige Änderungen Soweit es möglich ist, wurde in Linux 2.6 die Maximalzahl für bestimmte Ressourcen angehoben. Die Anzahl von möglichen Benutzern und Gruppen erhöhte sich von 65.000 auf über 4 Milliarden, ebenso wie die Anzahl der Prozess-IDs (von 32.000 auf 1 Milliarde) und die Anzahl der Geräte (Major/Minor-Nummern). Weitere leistungssteigernde Maßnahmen betrafen die I/O-Scheduler, das Threading mit der neuen Native POSIX Thread Library und den Netzwerk-Stack, der nun ebenfalls in den meisten Tests O(1) skaliert ist. Außerdem wurde für die Verwaltung der I/O-Gerätedateien das früher genutzte devfs durch das neuere udev ersetzt, was viele Unzulänglichkeiten, wie zum Beispiel ein zu großes /dev/-Verzeichnis, beseitigt. Außerdem kann so eine einheitliche und konsistente Gerätebenennung erfolgen, die beständig bleibt, was vorher nicht der Fall war. Lizenzbesonderheiten Proprietärer Code und Freiheitsbegriff Die heute von Linus Torvalds herausgegebene Fassung des Kernels enthält proprietäre Objekte in Maschinensprache (BLOBs) und ist daher nicht mehr ausschließlich Freie Software. Richard Stallman bezweifelt sogar, dass sie legal kopiert werden darf, da diese BLOBs im Widerspruch zur GPL stünden und die Rechte aus der GPL daher erlöschen würden. Resultierend daraus rät die Free Software Foundation deshalb dazu, nur BLOB-freie Versionen von Linux einzusetzen, bei denen diese Bestandteile entfernt wurden. Linux-Distributionen mit dem Kernel Linux-libre erfüllen diesen Anspruch. Der Kernel unter der GPL 2 Die bei GPL-Software übliche Klausel, dass statt der Version 2 der GPL auch eine neuere Version verwendet werden kann, fehlt beim Linux-Kernel. Die Entscheidung, ob die im Juni 2007 erschienene Version 3 der Lizenz für Linux verwendet wird, ist damit nur mit Zustimmung aller Entwickler möglich. In einer Umfrage haben sich Torvalds und die meisten anderen Entwickler für die Beibehaltung der Version 2 der Lizenz ausgesprochen. Literatur * Wolfgang Mauerer: Linux-Kernelarchitektur. Konzepte, Strukturen und Algorithmen von Kernel 2.6. Hanser Fachbuchverlag, München u. a. , ISBN 3-446-22566-8 * Robert Love: Linux-Kernel-Handbuch. Leitfaden zu Design und Implementierung von Kernel 2.6. Addison-Wesley, München u. a. , ISBN 3-8273-2204-9 * Jonathan Corbet, Alessandro Rubini, und Greg Kroah-Hartman: Linux Device Drivers. 3. Auflage, O’Reilly. , ISBN 0-596-00590-3 Weblinks Englisch: * The Linux Kernel Archives – offizielle Website * Elixir Cross Referencer * Interactive Linux Kernel Map * Linux Kernel Newbies – Infos für angehende Kernel-Programmierer * Oldlinux.org – eine Sammlung historischer Kernel * Linux 0.01 News – Seite zur Weiterentwicklungen des 0.01-Kernels für neuere GCC-Versionen * Anatomy of the Linux kernel – IBM, am Deutsch: * Linux-Kernel – Golem * [https://www.heise.de/thema/Linux_Kernel Linux Kernel] – Heise * [https://www.computerbase.de/downloads/system/linux-kernel/ Linux Kernel Download] – ComputerBase Einzelnachweise Kategorie:Linux-Betriebssystemkomponente